Date: Sat, 18 Jun 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #122 To: tcp-group-digest TCP-Group Digest Sat, 18 Jun 94 Volume 94 : Issue 122 Today's Topics: NOS & PLIP.COM Standard Digital Radio Interface Proposal (19 msgs) subnetting question Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 17 Jun 1994 11:54:22 -0700 From: corbin@uclahep.physics.ucla.edu Subject: NOS & PLIP.COM To: tcp-group@ucsd.edu Howdy all - Is anyone out there sucessfully running PLIP.COM (Crynwr's parallel port packet driver) with any of the JNOS variants? I finally soldered up the parallel port equivalent of a null-modem cable, set the driver running on both machines, set JNOS108dfd running on both machines, plugged in the cable, and ... ^@$@%! Nothing! For what it's worth - these are the commands I used to try to get things running: On wy6s.ampr.org.: I used the command: plip 0x60 0x7 0x378 00:00:00:33:11:22 to start plip and added : attach packet 0x60 en0 8 1500 to autoexec.nos route add pc.wy6s en0 On pc.wy6s.ampr.org.: I used the command: plip 0x60 0x7 0x378 00:00:00::11:22:33 to start plip and added : attach packet 0x60 en0 8 1500 to autoexec.nos route add wy6s en0 According to PKTCHK and TRACE, the sending PLIP thinks it's sending packets just fine - but the receive end gets one 'err_in' for each attempted packet sent... Has anyone else had better luck? Thanks & 73 //Brent wy6s@wa6epd.ampr.org. corbin@physics.ucla.edu. ------------------------------ Date: Fri, 17 Jun 1994 14:15:53 +0200 (DST) From: Gerard J van der Grinten Subject: Standard Digital Radio Interface Proposal To: nelson@crynwr.com (Russell Nelson) > > From: "Louis A. Mamakos" > Date: Thu, 16 Jun 1994 23:45:33 -0400 > > Clever folks could develop a small single board computer to terminate > the ethernet in a device, and which contains a simple ROM-based > software module to do generic sorts of things. Hook it (or build it > into) things like radios, rotator boxes, etc. > > Yes! Yes! Yes! Sixteen bits of digital I/O, and a sixteen bit D/A > and A/D would be enough for many purposes. Or maybe a daughter board > that implements the I/O? > > -russ ftp.msen.com:pub/vendor/crynwr/crynwr.wav > Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key > 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light > Potsdam, NY 13676 | LPF member - ask me about the harm software patents do. > Guess you are avoinding the fundamentals... It is the interface to the radio we all want. (wanna plug on my HH. where i can pumt 2Mb/s into on its 25kc channel) The family of daughters and son (sun) boards come later.... Regards, Gerard. -- Gerard J van der Grinten pa0gri@net.pa0gri.ampr.org [44.137.1.1] Elzenlaan 8 gvdg@nlr.nl (temporary qrl) 3467 TJ Driebruggen gvdg@fridley.pa0gri.ampr.org (home) Netherlands (+031)-34871606 Home. (+031)-52748435 Qrl. ------------------------------ Date: Fri, 17 Jun 94 14:58:32 +0100 From: agodwin@acorn.co.uk (Adrian Godwin) Subject: Standard Digital Radio Interface Proposal To: tcp-group@UCSD.EDU > From: brian@nothing.ucsd.edu (Brian Kantor) > > I'd really recommend the use of RS-485 and RS-530 instead of once again > creating our own unique-to-ham-radio incompatable-with-the-world > interface. > > What we're talking about here is just a radio modem. It's no different > from a wireline, optical, or other modem as far as its interface needs; > we can (and SHOULD) use established standards wherever we can. The ones > mentioned above aren't even a bad fit. > > - Brian I'd agree, but Jeffrey felt that the standards he'd looked at weren't suitable. Why was that ? And did you look at enough standards ? -adrian > From: "Louis A. Mamakos" > > If we really wanted to push the state-of-the-art (Ha!), why not define > the interface as ethernet, which will be plenty fast enough. Boards > for PeeCee boxes are less than $100, and you can hang a bunch of > "things" on an ethernet segment. That's at a different level though - it's perfectly reasonable where you've replace the TNC with a gateway / router, but there's a place for an interface between such a box and the analogue hardware. Eventually, it would be desirable if this interface vanished inside the ethernet-radio, but I stil think it's worth defining for now. There are some areas where the tnc<->modem doesn't cut cleanly, though - per-packet power control and carrier-sense is one area, and channell access other than CSMA (e.g. token passing or intelligent hub) is another. These can be stretched into a system by putting more intelligence into the radio/modem unit, but it doesn't seem to fit that well. > You need only define a protocol to run over the net to carry frames of > stuff between the various devices. If you were *really* clever, you > could also transport PCM audio this way too. > > Clever folks could develop a small single board computer to terminate > the ethernet in a device, and which contains a simple ROM-based > software module to do generic sorts of things. Hook it (or build it > into) things like radios, rotator boxes, etc. > Another, incompatible protocol ? :-). TCP seems too much software for this sort of box .. is UDP feasible, to avoid all the fragmentation stuff ? Anyhow, someone will point out that the cheapest way to do this is with a PC and an I/O board. Another monstrous great box/PSU/fan when a eurocard box was all that was wanted. -adrian ------------------------------ Date: Fri, 17 Jun 1994 10:10:40 -0400 From: "Louis A. Mamakos" Subject: Standard Digital Radio Interface Proposal To: Gerard J van der Grinten > Guess you are avoinding the fundamentals... It is the interface to the radio > we all want. (wanna plug on my HH. where i can pumt 2Mb/s into on its > 25kc channel) I thought the original request was for a digital interface between things like computers and the internal "modem" in a radio. If this is the case, then there was some perception that existing industry standard interconnections like RS232 are somehow limiting. I just suggested that if we're to invent something new, invent something that will be useful for a decade or more. Louis A. Mamakos, WA3YMH louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 ------------------------------ Date: Fri, 17 Jun 1994 10:04:21 -0400 From: goldstein@carafe.tay2.dec.com Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu Uh, let's figure out who's doing what. The original proposal was for a modem-style connector. It proposed a specific form factor (mini-15 pin) in order to fit onto small radios. All of the modulation,D/A, etc., is left to the radio, since it's an interface to a digital radio. Swell. Counterproposal from Brian: Use a standard modem interface, since they may already do the job. Swell. Unanswered minor issue: Do standard interfaces (485/530 et al) handle clocking the way radios will need it? Will radios be different from wireline modems (i.e., does DCE radio or DTE provide TxC)? Counterproposal from Louie: Put Ethernet in Digital radio. My comment: Yeah, right. Just what a 10 oz. (that's about 280g to the rest of the world) pocket radio needs, all that protocol. Suggestion from me: Everybody first state what you're trying to accomplish then propose how, not the other way around. I think the original was reasonably clear on the former, but only implicitly. Do we want a modem-style interface, or an electrically-heavy multiplexed interface (like Ethernet, ISDN, ST-bus, etc.)? fred k1io ------------------------------ Date: Fri, 17 Jun 94 09:21 EDT From: nelson@crynwr.com (Russell Nelson) Subject: Standard Digital Radio Interface Proposal To: louie@alter.net Cc: nelson@crynwr.com (Russell Nelson), tcp-group@UCSD.EDU, brian@nothing.ucsd.edu From: "Louis A. Mamakos" Date: Fri, 17 Jun 1994 10:10:40 -0400 > Guess you are avoinding the fundamentals... It is the interface > to the radio we all want. (wanna plug on my HH. where i can pumt > 2Mb/s into on its 25kc channel) I thought the original request was for a digital interface between things like computers and the internal "modem" in a radio. If this is the case, then there was some perception that existing industry standard interconnections like RS232 are somehow limiting. I just suggested that if we're to invent something new, invent something that will be useful for a decade or more. Seriously. If you have a 10Mbps microwave link, how else to connect to it than Ethernet? Besides which, the world *really* needs an ultra-low-cost TCP/IP device. The original KA9Q ran on a CP/M machine, so why can't we make an embedded system that's small and cheap? -russ ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do. ------------------------------ Date: Fri, 17 Jun 1994 12:04:38 -0400 From: "Brandon S. Allbery" Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu In your message of Fri, 17 Jun 1994 10:04:21 EDT, you write: +--------------- | Counterproposal from Louie: Put Ethernet in Digital radio. My comment: | Yeah, right. Just what a 10 oz. (that's about 280g to the rest of the | world) pocket radio needs, all that protocol. +------------->8 Yup. For what we seem to be looking for, proposals like Ethernet, ISDN, SCSI, IEEE-488, etc. seem to be massive overkill. "Smart radios" might be a separate idea worth following up, perhaps as an alternative to the proposed IP TNC (I think that's being discussed on nos-bbs, not here), but they're not the issue I understood to be in question here. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org Friends don't let friends load Windows NT. Linux iBCS2 emulation ------------------------------ Date: Fri, 17 Jun 1994 10:33:01 -0600 From: jra1854@tntech.edu (Jeffrey Austen) Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu > From: "Louis A. Mamakos" > Clever folks could develop a small single board computer to terminate > the ethernet in a device, and which contains a simple ROM-based > software module to do generic sorts of things. Hook it (or build it > into) things like radios, rotator boxes, etc. > >From: russ >Yes! Yes! Yes! Sixteen bits of digital I/O, and a sixteen bit D/A >and A/D would be enough for many purposes. Or maybe a daughter board >that implements the I/O? I think you're missing the whole point. The primary goal of this interface is to help the *end user* with setting up their station: eliminate custom cables, recalibration anytime something is changed, etc. A few items have been added so that most "sophisticated users" (e.g., pacsat, network nodes, higher speed, etc.) and experimenters will find the interface useful -- but not all of them; that would be impossible. Jeff, k9ja +-+ Jeffrey Austen | Tennessee Technological University jra1854@tntech.edu | Box 5004 (615) 372-3485 | Cookeville Tennessee 38505 U.S.A. ------------------------------ Date: Fri, 17 Jun 94 14:52:47 PDT From: Jon Albers Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu I am just getting into this discussion, but it seems to me that the goal has gotten a bit muddled. YES! We DO NEED a cheap and simple (dirty?) TCP/IP engine. There was an attempt to get KA9Q into a ROM and put onto a TNC which had some success. The newer TNCs (Like the Kantronics KPC-3) seem to have quite a bit more power than the origional TNC-2s did. But, that is a different project than a "SDRI"?? Isn't the goal here to simplify the development and use of modem and TNC hardware?? ------------------------------------- Name: Jon Albers ( jalbers@ka3ovk.is.irs.gov) Internal Revenue Service, Headquarters Information and Communications Services (HQ:I:I),810 7th St., NW, 2nd Floor Washington, DC 20001 ------------------------------ Date: Fri, 17 Jun 94 14:19 EDT From: nelson@crynwr.com (Russell Nelson) Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu Date: Fri, 17 Jun 1994 10:33:01 -0600 From: jra1854@tntech.edu (Jeffrey Austen) > From: "Louis A. Mamakos" > Clever folks could develop a small single board computer to terminate > the ethernet in a device, and which contains a simple ROM-based > software module to do generic sorts of things. Hook it (or build it > into) things like radios, rotator boxes, etc. > >From: russ >Yes! Yes! Yes! Sixteen bits of digital I/O, and a sixteen bit D/A >and A/D would be enough for many purposes. Or maybe a daughter board >that implements the I/O? I think you're missing the whole point. Probably. Sorry about that. I just get excited whenever anyone proposes a small embedded system that is only designed to do one or two things and can talk TCP/IP. -russ ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do. ------------------------------ Date: Fri, 17 Jun 1994 16:57:13 -0400 From: "Louis A. Mamakos" Subject: Standard Digital Radio Interface Proposal To: "Brandon S. Allbery" > Yup. For what we seem to be looking for, proposals like Ethernet, > ISDN, SCSI, IEEE-488, etc. seem to be massive overkill. "Smart > radios" might be a separate idea worth following up, perhaps as an > alternative to the proposed IP TNC (I think that's being discussed > on nos-bbs, not here), but they're not the issue I understood to be > in question here. So we're not trying to do something new; fine. So what's wrong with RS232 on a DB9, or are we just arguing over a new type of connector body? Louis A. Mamakos, WA3YMH louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 ------------------------------ Date: Fri, 17 Jun 1994 16:31:05 -0700 (PDT) From: rosenaue@mprgate.mpr.ca (Dennis Rosenauer) Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu According to Louis A. Mamakos: > > So we're not trying to do something new; fine. So what's wrong with > RS232 on a DB9, or are we just arguing over a new type of connector > body? > I agree with this idea. Why not use the appropriate commercial standard for the speed we are working at. If it is low speed use RS-232, for 56K use V.35 etc. But one your choose a standard, don't "bastardize" it stick with the signal levels, signal senses and timing contraints. >From personal experience in working on 56K amateur packet a lot of the test equipment, such as bit error rate test sets etc., would connect a lot easier to the modem or router if it had an industry standard interface. Of course with most industry standards, there are so many standards to choose from. I wouldn't get too worried about a given connector but I would really like to encourage the use of proper levels and timing for a given interface. Making up a cable with the appropriate connectors at each end is easy, level and timing translation is much more difficult. Just my $0.02 worth. -- Dennis Rosenauer VE7BPE rosenaue@mpr.ca MPR Teltech Ltd. Wireless Transmission Products "For every vision there is an Burnaby, B. C. equal and opposite revision" ------------------------------ Date: Fri, 17 Jun 1994 21:09:44 -0500 (CDT) From: Jeffrey Austen Subject: Standard Digital Radio Interface Proposal To: tcp-group@UCSD.EDU We seem to have several thoughts mixed together in this thread. I find the idea of an ethernet interface or an IP TNC interesting, but both of these are quite different than what I am proposing. Here are my goals: - the principal audience is the end users and the operators of packet "infrastructure" (digipeaters, nodes, links, etc.) - should be compatible with all current modulation and coding schemes - should be compatible with most anticipated modulation and coding schemes - must be easy to use --- plug-n-play is the primary goal --- I and many others are tired of this radio-tnc interface hack that we've been using for way too long (not that it wasn't a good idea at the time; it's just long past the time to come up with something better) - must be simple enough to be built into future radios (e.g., the next generation of mobile radios and even some handhelds) Here is what I am *not* trying to do: - replace computers, TNCs, or other boxes - any form of data processing - be a technology leader I have looked at existing serial interface standards, at least the ones I could find documented in our library (which does not include EIA-530) and a few others. The asynchronous interfaces will not work with the PSK satellite modems nor the GRAPES modems as they are both synchronous. By performing clock recovery in the radio we can use a synchronous interface for everything -- therefore I choose a synchronous interface. The synchronous interfaces that I have seen are all too complicated in that they have many signals which are not needed for this application, have several ways that they can be used, and use physically large connectors with many pins. I decided that the best solution is to use what I can of the standards (electrical signaling levels) and define the signals needed for this application. I hope this clarifies my intentions. Jeff, k9ja +-+ Jeffrey Austen | Tennessee Technological University jra1854@tntech.edu | Box 5004 (615) 372-3485 | Cookeville Tennessee 38505 U.S.A. ------------------------------ Date: Fri, 17 Jun 1994 22:17:03 -0400 (EDT) From: DJ Gregor Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu Here are a few things that I think should be clarified. First, I will refer to the "Data Radio" or "DR" as a modem, and the "TNC" as the communications controller. This is because the interface is actually between the modem and the communications controller, not neccisarily between a TNC and a Data Radio. > To send data from the TNC to the DR the following items are necessary. > - Transmit Data: the data from the TNC to the DR. > - Transmit Clock: a clocking signal for the transmit data, originating > at the DR. > - Request To Send: a signal from the TNC to the DR indicating that > data transmission is requested. > - Clear To Send: a signal from the DR to the TNC indicating that data > transmission may proceed. [[ stuff deleted ]] > Much of the delay necessary at the beginning of the transmission are > due to internal delays in the transmitter. This delay is made the > responsibility of the DR rather than the TNC. When CTS becomes active, > data can be sent immediately; after the last bit of data has been sent, > RTS may become inactive. Additional delay may be added in the TNC (as > is done currently). The data should be valid on the rising edge of the clock. The clock should be 1X. This is a simple setup and can be used with the popular Z8530 IC. Both clocks should be provided by the modem. This way, the communication controller can be dumb and just use the clocks from the modem. The data should not contain any encoding such as NRZI or manchester. Let the modem worry about it--keep this thing plug and play. When the modem has a data stream and a good clock, the "Receive Data Valid" should be high. When the communications controller has data that it is ready to send, it should raise "Request to Send" line and start sending flags. The modem should immediately prepare to transmit. During this time when the trans- mitter is keying up, the modem can either send the flags from the communication controller, or send some other kind of waveform to prepare the receiving stat- ions for data. When the "Clear to Send" line is active, the communication con- troller should send at least one more flag, and then start sending data. When it is done sending data, it should send at least one flag, bring down the RTS line, and keep sending flags. The modem can keep the transmitter keyed if needed. The communications controller should NOT add any of its own 'keyup delay' because circuitry in the modem (it can even be a 555 timer) should take care of it. I do NOT think that it is a good idea to use the RS-232 protocol. It is most commonly used today as an asychronous protocol, and we are using synchronous data. If we did hack RS-232 into an interface like this, we would have a number of people trying to plug this into a COM port on their PC. This is a good interface and I think that it should be TOTALLY plug and play. I would like to see some information on IC's that can do TTL/RS-422/423 conver- sions. ----- DJ Gregor, N8QLB dgregor@bronze.coil.com "...oh, you use DOS, sorry to hear that..." ------------------------------ Date: Fri, 17 Jun 1994 19:46:17 -0700 (PDT) From: jerry@tr2.com (Jerome Kaidor) Subject: Standard Digital Radio Interface Proposal To: agodwin@acorn.co.uk (Adrian Godwin) Adrian Godwin wrote: > > Anyhow, someone will point out that the cheapest way to do this is with a > PC and an I/O board. Another monstrous great box/PSU/fan when a eurocard > box was all that was wanted. **** Doesn't have to be monstrous. There are tiny PC motherboards out there. You don't have to use a hard drive; the firmware could be burned into a custom ``bios rom'', a socket for which they all have. You don't need a display and keyboard, either. Just a network interface, and some I/O. The network i/f could be laid down on its side, making for a nice small package. After all, the ISA bus is slow and conservative; should be no problem to make it work through a couple inches of ribbon cable.... - Jerry Kaidor, KF6VB ------------------------------ Date: Sat, 18 Jun 1994 02:30:55 -0400 From: "Louis A. Mamakos" Subject: Standard Digital Radio Interface Proposal To: Jeffrey Austen > - should be compatible with all current modulation and coding schemes How would the interface be complatible? This is what sort of confused me before when I suggested using an ethernet-type interface. > I have looked at existing serial interface standards, at least the ones I > could find documented in our library (which does not include EIA-530) and a > few others. The asynchronous interfaces will not work with the PSK satellite > modems nor the GRAPES modems as they are both synchronous. By performing > clock recovery in the radio we can use a synchronous interface for everything > -- therefore I choose a synchronous interface. The synchronous interfaces > that I have seen are all too complicated in that they have many signals which > are not needed for this application, have several ways that they can be used, > and use physically large connectors with many pins. I decided that the best > solution is to use what I can of the standards (electrical signaling levels) > and define the signals needed for this application. But, RS232 *is* a synchronous-capable interface. If you look on a DB25 connector, there are transmit and recieve clock signals, as well as CTS and RTS used by half-duplex synchronous modems. I've run RS232 synchronous well above 56Kbps. So, what's wrong with RS232? Synchronous interfaces don't have to be complicated - all you need is what you use for async RS232 and add a couple of clock signals. V.35 is essentially the same sort of signals as RS232 except that the transmit and recieve data and clock signals are balanced signals (two pins each) whilst the remaining signals are essentially the same single-ended RS232 levels. Louis A. Mamakos,WA3YMH louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 ------------------------------ Date: Sat, 18 Jun 1994 10:40:56 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: Standard Digital Radio Interface Proposal To: agodwin@acorn.co.uk (Adrian Godwin) > > Clever folks could develop a small single board computer to terminate > > the ethernet in a device, and which contains a simple ROM-based > > software module to do generic sorts of things. Hook it (or build it > > into) things like radios, rotator boxes, etc. > > > > Another, incompatible protocol ? :-). TCP seems too much software for > this sort of box .. is UDP feasible, to avoid all the fragmentation stuff ? The protocols are already there. Just use SNMP to manage it all. If vendors can demo an SNMP controlled toaster I think we can cope with radio. SNMP needs only IP and UDP. Alan ------------------------------ Date: Sat, 18 Jun 1994 10:38:15 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: Standard Digital Radio Interface Proposal To: nelson@crynwr.com (Russell Nelson) > Seriously. If you have a 10Mbps microwave link, how else to connect > to it than Ethernet? Well ideally I guess you make the PC interface card look like an NE2000 clone. > Besides which, the world *really* needs an ultra-low-cost TCP/IP > device. The original KA9Q ran on a CP/M machine, so why can't we make > an embedded system that's small and cheap? > I'd second this. With a 68HC11 you've just about got enough power to handle say 38.4K TCP/IP at a very low cost. BPQ on a PC is a TSR node that can do IP stuff but not ip->ax25 conversion or directly IP services. Alan ------------------------------ Date: Fri, 17 Jun 94 19:02:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Standard Digital Radio Interface Proposal To: tcp-group@UCSD.EDU Cc: goldstein@carafe.tay2.dec.com g> Unanswered minor issue: Do standard interfaces (485/530 et al) handle g> clocking the way radios will need it? Will radios be different from g> wireline modems (i.e., does DCE radio or DTE provide TxC)? If you can find a surviving wireline modem in 10 years, I'll be surprised. You ought to read that neat new book, "ISDN in Perspective." I forget the author's name. :-) g> Counterproposal from Louie: Put Ethernet in Digital radio. My comment: g> Yeah, right. Just what a 10 oz. (that's about 280g to the rest of the g> world) pocket radio needs, all that protocol. Look at the bright side: it would already have the BNC connector. -- Mike ------------------------------ Date: Fri, 17 Jun 94 18:52:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Standard Digital Radio Interface Proposal To: tcp-group@UCSD.EDU Cc: brian@nothing.ucsd.edu BK> I'd really recommend the use of RS-485 and RS-530 instead of once again BK> creating our own unique-to-ham-radio incompatable-with-the-world BK> interface. I certainly agree with your objection to creating a new interface. BK> What we're talking about here is just a radio modem. It's no different BK> from a wireline, optical, or other modem as far as its interface needs; BK> we can (and SHOULD) use established standards wherever we can. The ones BK> mentioned above aren't even a bad fit. I don't agree that RS-485 and RS-530 are good choices. The cost of the cheapest existing hardware which implements them is several times the cost of a TNC. I still think Ethernet is the most promising contender, since it is very, very cheap and well standardized. After all, we are supposed to be playing TCP/IP here. -- Mike ------------------------------ Date: Fri, 17 Jun 94 15:58:00 EDT From: "Patterson, Gary" Subject: subnetting question To: tcp-group@ucsd.edu Forgive me, this is not directly related to ham radio, but I know there are tcp experts here. I am the admin of a Class B Internet address space. Can I have an east coast and west coast site that advertise subnets of my Class B space through two different service providers? Or, must I only advertise my Class B network address from one point, and then subnet beneath that point? TNX and 73 Gary Patterson AA4UR patterso@anser.org ------------------------------ End of TCP-Group Digest V94 #122 ******************************